home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / programs / xrs510.zip / NEWIN510.DOC < prev    next >
Text File  |  1993-02-04  |  67KB  |  1,164 lines
  1. XRS version 5.10 is a non-beta public release of XRS 5.04 "Wide Beta"
  2.  
  3.  
  4. A *Special* note to long-time XRS users:  (and v 5.0 "Mod 4"+ users!)
  5.  
  6.   Even if you have stuck with "Page View" (scrolling screen-at-a-time)
  7.   message viewing since 'day 1', you likely want to try the new optimal
  8.   viewing mode again: multi-screen messages are now displayed with all
  9.   menubar options available at all times, etc. - see item #36 in the
  10.   section on changes from 5.00 -=> 5.01 below!  Item #36 was greatly
  11.   enhanced for 5.01, even if you have XRS 5.0 with "Mod 4" or "Mod 5"
  12.   patches applied - read it again!
  13.  
  14.  
  15. Fixes in 5.10, not found in 5.04 "Wide Beta":
  16.  
  17. 1) XRS properly finds bbs_id_.ORG files in the current directory for a
  18. specific BBS and 'locks' the origin lines for those conferences if you wish,
  19. and it also doesn't screw up "RANDOM.ORG" for other areas if XRS.ORG is in
  20. the current directory (and not on the PATH instead).  'bbs_id_' above must
  21. match the name of the downloaded mailbag - exactly seven characters (pad it
  22. with underscores to make seven characters if needed; i.e.: RHOUSE_.ORG).
  23. Further, XRS.ORG being in the current directory actually sends the proper
  24. chosen origin line for the area, instead of your default ORIGIN.XRS brag.
  25.  
  26. 2) The "Alias is Name" (or "Name is Alias") parameter in CONFIG.XRS works.
  27. Fair Warning: Is you turn this parameter on, and you're not using a 12-step
  28. (or similar) BBS where you really do use your alias for your name, you are
  29. likely going to really make your SysOp angry, possibly causing banishment
  30. from the XRS system!  BE CERTAIN YOU QUALIFY TO USE THIS - IT IS MEANT ONLY
  31. TO ALLOW USERS OF BBSs THAT ALLOW USE OF AN ALIAS AS YOUR REAL NAME ON THE
  32. BOARD TO USE XRS TO ENTER MESSAGES INTO "ALIAS ONLY" AREAS.
  33.  
  34. 3) A low-memory data overwrite problem was detected in the startup routines
  35. with "Bounds Checker" v2.0 and corrected.  A total of four problems were
  36. found in various portions of my code and the "HX" code under varying
  37. conditions - probably been there 'forever'...  [for examples, the first call
  38. to "HX_Create()" would destroy interrupt vector 0 (division by zero) writing
  39. over a NULL pointer, but since I never divide by zero, it didn't matter - I
  40. now fix the interrupt vector immediately after it is mangled by the HX code.
  41.  
  42. 4) Many of the C_Worthy 1.21"MYR" routines were recompiled with Borland C++
  43. 3.1 with full optimization, resulting in a slightly larger, but noticably
  44. faster XRSCORE.DLL library.
  45.  
  46. 5) "Allow HiASCII" works only on "Brag" lines, allowing you to enter them
  47. in Chinese native language.  This parameter is intended ONLY for usage with
  48. the Taiwanese NLS support overlay available from Wen-Chung Wu.  YOU SHOULD
  49. NOT USE IT OTHERWISE! (Hi ASCII characters in English echomail well get you
  50. a nastygram from the infamous "GMD" program.)
  51.  
  52. 6) XRS no longer tests for Desqview when running under OS/2 (and therefore
  53. no longer displays erroneous messages about "Desqview 3.0" when you are
  54. running a program that tricks XRS into thinking DV is there, but is not).
  55.  
  56. 7) Copyright notices updated to include 1993.
  57.  
  58. 8) OS/2 2.x virtual UMA support for DOS is truly screwed up!  I have reported
  59. the problem(s) (which persist in the 2.1 beta) to IBM for repair: When UMBs
  60. are turned on (in the dialog "DOS Settings" under the "General" tab), OS/2
  61. will report 0 as the largest available block.  When it is turned off, OS/2
  62. will report a nonsense number, in my case 3072 (although no UMBs are
  63. available).  For the time being, XRS will report (unfortunate) reality as it
  64. sees it: if UMA support is on, it reports "No UMB Provider", since it sees 0
  65. as the largest available block - if UMA support is off, it will report "UMBs
  66. Hosed" and disable UMB allocation, since OS/2 is reporting total UMA is less
  67. then the largest UMB.  For the time being, I've decided to bastardize my code
  68. and try to correct the situation (when possible): if "Largest UMB = 0", I'll
  69. try to allocate them anyway, and correct the value which is reported by OS/2
  70. (if I can successfully allocate blocks).  Sometimes I get away with it, most
  71. of the times I don't - go figure - "don't ask me why, 'cause I dunno!".  Oh,
  72. well - when they fix it, it'll work <g>...  Of course, this is only going to
  73. affect you if you run XRS under OS/2 2.x!  OS/2 1.x has UMA support disabled
  74. since there is none provided in the "DOS Box" of OS/2 1.x versions.
  75.  
  76. 9) XRS properly detects OS/2 2.x "VXMS" services, even though a query for the
  77. "XMSXXXX0" device driver fails. (reported as "VXMS.Sys" just like QEMM, HiMem
  78. or 386^Max - with version number)
  79.  
  80. 10) XRInstal.Exe looks for "XRS510.ZIP", "XRS510XT.ZIP", "X386V510.ZIP" and
  81. "XRCFG104.ZIP" instead of previous version filenames.  If you need to install
  82. any other version, use "XRINSTAL -F" to change the <F>ilenames.
  83.  
  84. 11) XRS/386 only delays 1 1/2 seconds during the logo "rainbow/cascade".  It
  85. *is* <ESC>apable!
  86.  
  87. 12) XRS *always* puts a ^aPID line into every message, regardless of the
  88. setting of the "No Pids" parameter.  Turning off No Pids simply adds the
  89. old "--- XRS! 5.10+" (or similar) back to the tear line at the bottom.  Due
  90. to the truly screwed-up programs written by Gerard van der Land which
  91. violate FTSC standards and remove and/or alter either or both, the ^aPID
  92. line doesn't have a ":" after it any more, to attempt evasive action (so as
  93. to avoid his programs ripping them out and replacing them with his own).
  94.  
  95. 13) Ralf Brown's "SpawnO()" swapping utilites updated to version 4.13.
  96.  
  97. 14) A new '386 version of XRNeedle ("XRNDL386.EXE") which handles up to 1/4
  98. million messages in a single mailbag (with sufficient memory) is available
  99. in a separate archive: "XRNDL386.ZIP".  It is a 'flat 32-bit' DOS extender
  100. protected mode version, which uses all available memory.  (any XMS or 'raw'
  101. INT15-accessible extended memory)  Using DOS 32VM code, it takes less than
  102. 10 seconds to rethread a 15,000-message mailbag!
  103.  
  104. 15) XRS 5.10 has been tested under OS/2 2.1/beta, MS/DOS 6.0/beta2, QEMM386
  105. v 6.03 and QDPMI version 1.01 - all seem to be in working order mostly <g>...
  106. See however the note about OS/2 2.x virtual UMA support - it's screwed for
  107. now - as soon as it learns to play correctly, my code will work.
  108.  
  109. 16) All versions of XRS are distributed with PKZip 2.0x compression, and
  110. imbedded "-AV" (Authenticity Verification) which uses tighter compression
  111. and a new more secure -AV code system, to prevent faking and hacking the
  112. release files.  Note that PKUnZip.Exe 1.xx users will not see -AV (nor will
  113. they be able to extract any files from any of the archives, anyway) - "None
  114. genuine without my signature...".
  115.  
  116. 17) XRInstal.Exe should actually work without locking up at the end on '286
  117. machines (or any machine without an XMS driver loaded).  It also doesn't stop
  118. and make note that you have a wierd "286" chip, either.
  119.  
  120. ==== 5.10 non-beta watermark ====
  121.  
  122. 18) A condition which would occasionally cause XRS to display a message that
  123. should exactly fit into a single screen to 'blank out' was fixed.
  124.  
  125. 19) PKZip 2.04e used to compress and for "Authenticy Verification".
  126.  
  127. 20) The ability to hit '-' (for previous message) during a multi-screen
  128. message using "Screen-at-a-Time" viewing works properly again.  You can
  129. hit 'S', '+', <ESC> or the 2nd letter on the bottom line to skip forward.
  130.  
  131.  
  132.  
  133.  
  134. XRS version 5.04 is a "Wide Beta" public release of XRS 5.04/alpha6:
  135.  
  136.  
  137. (for changes between versions 5.02 -> 5.03 and 5.01 -> 5.02, etc see below)
  138.  
  139. 1) Borland C++ 3.1 compiler patches two and three applied.  Who knows?
  140.  
  141. 2) XRS no longer leaves "BATxMAIL.XRS" open if you <ALT_F10> exit from the
  142. program (which caused 'Share' violations when I tried to reuse it at exit).
  143. (Reported by Johnathan Hutchins numerous times, just couldn't find it...)
  144.  
  145. 3) I changed the spelling of "Receipient" to "Recipient" (good eyes, Daan! -
  146. I thought you were Dutch <g>...)
  147.  
  148. 4) The special '386 version is under development - currently only available
  149. to alpha test team members.  It features true '386 code generation, smaller
  150. (much!) compressed overlay (RESP_386.DLL) for a 64K disk space size saving.
  151. Adding the true DOS/386 extender isn't going to be easy until Borland
  152. 'fesses up with a true 32-bit *.OBJ compiler, though...  RESP_386.EXE
  153. requires a minimum of 2MB memory with 1MB either EMS or XMS.
  154.  
  155. 5) I had to change the <F3> to send "UserRequest" to <CTRL_F3>, because it
  156. was screwing everything else that 'keyed' on <F3> before (like modify the
  157. message subject/to/area/etc once written, etc).  (per bonehead Mike)
  158.  
  159. 6) A new CONFIG.XRS parameter "Show Gateways" forces XRS to display any
  160. 'secondary' origin lines it finds.  If you want them to be quotable, you
  161. must set the "Quote Kludges" option on as well.  (per request - Rudi)
  162.  
  163. 7) "XRInstal" v 1.0 compiled with "Builder" <tm> v 2.03 is included.  This
  164. should eliminate the problem(s) with '286 machines hanging near the end of
  165. the install procedure.
  166.  
  167. 8) Wierd message numbers displayed (especially if you were backing up) for
  168. "XX of YY" (messages) in "To You" mode with "New Only" on fixed.
  169.  
  170. 9) XRS checks for message marked for deletion even when a mailbag has been
  171. completely read - however, you can never mark all messages and delete them
  172. (and end up with an 'empty' mailbag - XRS won't let you do so...).
  173.  
  174. 10) In the UCC/TELOS version (non-shareware), <F4> doesn't pop up the whole
  175. mess (it's back like it was before - a shortened, select list of options).
  176.  
  177. 11) The "Select Area" group names may optionally be sorted (by name instead
  178. of in numeric order).  To enable this option, put "AreaName Sort" in your
  179. CONFIG.XRS file.
  180.  
  181. 12) If the "New Only" filter is on, hitting <DEL> when any message area is
  182. highlighted will require you to confirm marking all messages in that list
  183. 'read'. (i.e. remove them from the list of messages to be read)  When the
  184. "To You" filter is on, this only affects messages to you, otherwise, it is
  185. designed to easily mark 'read' a group of messages you don't want to read.
  186. As part of this, "auto-cycle" to the last remaining area no longer occurs
  187. (XRS used to 'auto-cycle' if only one area was left, regardless of the way
  188. you set the "Auto Cycle" parameter - now it doesn't, otherwise, you could
  189. never mark the last area 'read' if you needed to!)  By the way: unless you
  190. have the "Auto Cycle" feature turned OFF, this won't be available...
  191.  
  192. 13) XRS improperly deciding "=-=-=-=-=" in the middle of a message was the
  193. end of a message was fixed (again) - reported by Rich Veraa.
  194.  
  195. 14) "Universal" twitting wasn't working exactly as I planned - if the twit
  196. was in the "To Name", you still saw the message, minus the line with his
  197. name in it (reported by Jim Mork).  In conjunction with this, I disabled
  198. the 'proximity' twitting (only twit by "From Name" and not "To Name" nor
  199. "Subject" fields) if you put "From Twit" in your CONFIG.XRS.  Most people
  200. preffered it the original way...
  201.  
  202. 15) New XRCfg102.Zip adds "Show Gateways", "From Twit" and "AreaName Sort"
  203. to options recognized and setable in the configuration utility.
  204.  
  205. 16) XRS knows an 'i486SX' CPU when it sees one.  Note: the 'relative power'
  206. is computed using integer arithmetic, so it seems to be quite happy with
  207. "DX2" (or "Overdrive") processors <grin>...  (actually, XRS does absolutely
  208. *no* floating point arithmetic - even fractional numbers displayed are
  209. computed using integer algebraic formulas.)  An i486/66DX2 rates 97.4!
  210.  
  211. 17) In 5.04/a1 XRS would spend eternity looking for the first message or
  212. display the whole BATxMAIL.XRS during "All Read" looking for the top of the
  213. mailbag identifyer which was introduced in the bug-fix #13 above - fixed.
  214. (It must have been there for a *long* time, just never uncovered until I did
  215. the repair to #13 above correctly - I had an unsigned field in one module
  216. that was an integer in another - guess it's time to break out "PC/Lint" again
  217. - I *despise* that darn obnoxious nit-picking thing! <g>...)
  218.  
  219. 18) If you export a message you are viewing (not one you wrote yourself...)
  220. then invalid output device name doesn't cause a repetitive sequence of error
  221. messages - one per line in the message - it 'escapes' at the first error.
  222.  
  223. 19) XRS releases time-slices after each message is displayed and when waiting
  224. for an input event under OS/2 2.0 or later (same as it does under DesqView).
  225. Note that XRS is not 'fooled' by programs that cause XRS to think both OS/2
  226. and DesqView are active - only OS/2 time-slicing is executed in this case.
  227.  
  228. 20) XRS/386 no longer 'doubles' the prompt when you <F10> Shell-to-DOS the
  229. second (or successive) time.
  230.  
  231. 21) XRS 'weeds out' the string removing multiple spaces when displaying the
  232. item (area #, name, etc) when confirming an area deletion if you hit <DEL>
  233. while the message area selection pick-list is displayed.  (i.e. it displays
  234. Mark "002  XYZ  2 unread" 'read'? instead of "002  XYZ          2 unread"...)
  235.  
  236. 22) XRS allows OS/2 2.x sessions to use Upper Memory Blocks as long as any
  237. UMB provider is accessible.  If the calls to "UMBTotal" and "UMBLargest" are
  238. contrary (which I seem to see a lot!), then XRS will disable UMB functions.
  239. XRS displays "UMB's hosed!" on the <F2> screen when it notes this condition.
  240.  
  241. 23) Under the TELOS/UCC (non-shareware) version, the option <CTRL_F3> to
  242. send a "User Request" is not displayed or active.
  243.  
  244. 24) Under any system which doesn't have a "LOCAL" group which is remapped
  245. to group 0, XRS doesn't create a 'Local' group 0 - one which allows users to
  246. enter new messages into the (non-existant) local area.
  247.  
  248. 25) The bug in RTLink+ 5.11/alpha3 which caused recent alpha XRS/386's to
  249. lockup on the 2nd external program call (or shell-to-dos) was worked around.
  250. Version 5.11/beta7 still elicits the same problem, although I have not been
  251. able to narrow it down to a small enough example for them to diagnose.
  252.  
  253. 26) XRS/386 will only be available direct from me and is protected by both a
  254. different name CRC function, requiring an "XRS386.KEY" file be present to run
  255. in 'registered' mode (this allows you to run both earlier XRS's and the '386
  256. version without having to keep changing your keys back and forth), plus it
  257. requires that your own personal data be added to the RESP_386.EXE program!
  258. See registration form for updating to XRS/386 - which runs 15-20% faster, is
  259. capable of handling larger mailbags, and is 'tighter' code, both in terms of
  260. 386-code generation and smaller 'footprint' (by 60K!) in disk file size and
  261. will run 'TurboCached' in only 144K EMS and/or XMS (or combined) memory.  A
  262. fee of $15 plus your current registration key is required to update to '386.
  263. Remember: XRS/386 requires a minimum of 2MB of memory and a '386, '486 or
  264. Pentium(R) processor.  It is capable of using up to 32MB memory, currently.
  265. Note: XRS/386 is *NOT* shareware!  It will not run AT ALL unless registered.
  266.  
  267. 27) XRS is linked with RTLink+ 5.11/beta7 - not 5.11/alpha'x' - seems cured.
  268. It seems as though they were *really* hosing memory allocations somewhere...
  269. This version should eliminate several 'odd' lockups and crashes, as well as
  270. any shell-to-dos multiple lockups after "Restart", etc.
  271.  
  272. 28) A long-standing bug in CWorthy 2.11's "QuickSortList()" procedure was
  273. identified and fixed.  This error *really* screwed up memory allocation, and
  274. was likely responsible for other memory problems/side-effects even when it
  275. was successful...  The symptom would be a lockup, QEMM exception or similar
  276. when sorting any 'not normalized' mailindex.  Sometimes you would get a "DOS
  277. Critical Error" (bogus one, at that!), sometimes it would just hang.  Jeez -
  278. 0 for 2 - seems like I'd learn to quit trusting stuff I didn't write <g>...
  279. (reported repeatedly by David Dyer-Bennet & Daan van Rooijen - thanks guys!)
  280.  
  281. 29) A long-standing bug causing potential memory allocation problems in the
  282. "ClearSetBG()" routine was causing XRS to clear a non-existant area of the
  283. screen - potentially locking up on SuperVGA (> 50x80 geometry) displays.
  284. Well - three memory allocation potentially fatal bugs in a row - must be on
  285. to something!  This could well be the problem which caused DesqView to go
  286. nuts when the protection level was "set up", since it would cause XRS to try
  287. to write outside the program's assigned screen area before displaying each
  288. message in the mailbag.
  289.  
  290. 30) The "ColorCascade" of matching strings (and the flashing XRS logo) have
  291. been adjusted for better (more certain non-repeting) color rainbows.
  292.  
  293. 31) Under OS/2, XRS no longer "Pegs" when awaiting input strobing the mouse
  294. and keyboard 2000+ times per second.  I added code to low-level "INPUT.ASM",
  295. "USER.C" and "QUEUE.C" modules of C_Worthy to call a time-slicing interrupt
  296. any time no input is available (int 0x2f, AX = 0x1680).  The giving away of
  297. time-slices at other points in the program was removed under OS/2 (not under
  298. DesqView!), since it provides true multitasking and leaving them in makes
  299. XRS 'jerky'.  (thanks, geoffrey!)
  300.  
  301. 32) In addition to the above, a general "tick-watch" routine was installed
  302. to smooth the execution of "Rainbow" background routines (both the cascade
  303. of the "XRS" logo, and highlighted string matches in the message display)
  304. are limited to one color-change per internal clock tick (approx. 18.2 times
  305. per second).  The code doesn't take enough room or time to affect slower
  306. computers, but slows down newer model 486/50 & 66 models enough so that you
  307. get the old familiar rainbow color cascade instead of psychedelic flashback.
  308. To keep the "tick_tock()" routine from eating keystrokes (or making jerky
  309. response), InputStatus() is checked before waiting each tick (1/18th sec.).
  310.  
  311. 33) If you want XRS to automatically create threads (but not sort the mailbag
  312. into subject order, which sometimes may cause the answer to appear before the
  313. question if someone changes the reply to a lower-alphabetic subject), then
  314. use "XRNeedle.Exe" instead of XRS-Sort/XRSrt286/XRSrt386 as your Preprocess.
  315. Note that only rethreading (which forces creation of threads even if they do
  316. not exist in the output from your mailbagger) does *not* require normalizing
  317. the index each time it is read - which any XRS-Sort/286/386 use does require.
  318. XRNeedle.Exe is capable of handling a mailbag of up to 7500 messages.  If you
  319. always live within this 7500-message limitation, switching from XRS*Sort.Exe
  320. to XRNeedle.Exe will take slightly more time calling that specific program,
  321. but overall load time (and reload time for each subsequently load of the same
  322. mailbag) will be much faster since the index will already be normalized.  The
  323. XRNeedle.Exe program rethreads 6400 messages in 6.448 seconds on my machine,
  324. but normalizing a 6400-message index file takes over 21 seconds (XRNeedle
  325. displays time statistics down to 18.2 parts a second using integer algebra).
  326.  
  327. 34) If you want "Home" to actually skip back to the top of the thread and on
  328. to the next topic instead of just go back to the home message of the thread,
  329. then "Home Next" in CONFIG.XRS will cause XRS to automatically do a "Next"
  330. (or equivalent for your language) after going home to the top of the thread.
  331.  
  332. 35) XRS now properly detects any currently available CPU type whether or not
  333. a DPMI host is loaded (prior versions could only tell an i486 from an i386 if
  334. a DPMI host was loaded).
  335.  
  336. ---Wide Beta watermark--- (things not in /alpha1 through /alpha6)
  337.  
  338. 36) If you have XRS in "List View", XRS no longer 'jitters' the screen, first
  339. showing the message left-justified, then with the list scroll bar, then again
  340. left-justified and finally one more time with the list scroll bar.  Instead,
  341. the message is displayed in "Page View" mode actually, since there is no
  342. reason to put the scroll-bar on the left on a message that takes less than
  343. one full screen to display.  This basically means "List View" = "Optimal", so
  344. the old "Page View" parameter is now ignored, and the cycle in the <F4> online
  345. configuration window switches only between old-style "Page View" and "Optimal"
  346. modes (and not to "List View").
  347.  
  348. 37) "[A]gain" selected from the menu-bar now only clears the appropriate part
  349. of the screen instead of all of it, giving a less jerky repeat view.  This,
  350. combined with the above item also makes the general display of messages much
  351. quicker, since I don't have to allow for three different viewing 'modes'.
  352.  
  353. 38) XRS arrbitrates between background "Color Cascade" of matching strings and
  354. input (from keyboard or mouse) and always choses processing input over a color
  355. change sequence, providing less jerky movement when using the mouse (and even
  356. a little the keyboard arrows) if several strings are highlighted at one time
  357. in a scrolling message (more than one screen-full).
  358.  
  359. 39) XRS 5.04 "Wide Beta" is linked with RTLink+ 5.11 (not 5.11/beta'x').
  360.  
  361. 40) XRS/386 doesn't play any music by default.  If you want it to play charge
  362. and all that jazz, put "Music" into your CONFIG.XRS file.
  363.  
  364. 41) If XRS can tell, it displays the version number of your mouse driver in
  365. the place on the <F2> screen where it used to put "Mouse? YES".  Of course,
  366. if you're using a non-Microsoft mouse, the number returned may be 'cheated'
  367. by your mouse driver, reporting which level of the M/S version it supports.
  368.  
  369. 42) By request from "Bob R." - XRS now allows a 12-step or similar BBS to use
  370. your alias as your real name (or vice-versa if you will), doing so requires
  371. you place a parameter in your CONFIG.XRS file "Alias is Name" (or "Name is
  372. Alias" - they are synonyms).  This will allow Bob R. to write a message in an
  373. "Alias Required" area <g>...
  374.  
  375.  
  376.  
  377.  
  378. XRS "Wide Beta" version 5.03 is mostly a 'fix' for a few problems in 5.02:
  379.  
  380.  
  381. (for changes between versions 5.01 -> 5.02 and 5.0 -> 5.01 see below...)
  382.  
  383. 1) It didn't always find every match doing "AutoTag/Match" or <F8> searches.
  384. (Borland C++ 3.1 optimization bug - I didn't change anything from 4.5x to the
  385. current version, but juggling the lines around seems to cure it...)
  386.  
  387. 2) Changing your default origin line from the <F4> config window was fatal.
  388.  
  389. 3) PKUnZip's "-AV" feature was hosed on one release archive by my using a
  390. pre-release PKZip 1.93a on it accidentally.  The 1.93a version doesn't know
  391. anything about 1.1x versions' "-AV" functions (they will be different in the
  392. PKZip 2.x series requiring you get your PKZip with "-AV" protection direct
  393. from PKWare).  The 1.93a version was released to ASP authors by Phil.
  394.  
  395. 4) If you had "New Only" turned off the <J>ump list was *really* hosed!
  396.  
  397. 5) The full version number including sub-version (i.e. ".a2" for alpha2) is
  398. displayed in the tear line or ^aPID: line as well as in on-screen displays.
  399. This also allows for a five-byte "patch area" so that the Chinese native
  400. language version can show a proper designator (like "XRS 5.03Cxxxx").
  401.  
  402. 6) The "<Ins>ert file" routine was not displaying the 'target' subdirectory
  403. for you to pick a file from properly (if at all):  one line of code that
  404. hasn't changed in three years compiles to different assembler output under
  405. Borland C++ 3.1 for some reason - not sure if it's an optimization error or
  406. just a plain bug, but I changed the code to do it a different way, and
  407. everything works just fine again.  I also tweeked this routine so it doesn't
  408. use an oversized, mostly blank pick-list if there are only a few filenames.
  409.  
  410. 7) XRS doesn't truncate the version information at 25 characters (it can be
  411. up to 35 characters including the leading "--- ").
  412.  
  413. 8) The first 'page' of the <F2><F2> "HeapWalker" routine displays credits
  414. for development tools used to create the current version of XRS, as well as
  415. the internal revision number.  The internal revision number consists of the
  416. julian date plus make number - i.e. "92206.03" being the third time XRS was
  417. compiled on July 26th, 1992.  The 'background procedure' if any (timeclock,
  418. editor status, etc) is disabled during this routine.
  419.  
  420. 9) XRS enforces the "Filename" filter (no imbedded spaces, UPPERCASED as you
  421. type it, etc) when you type in a subdirectory name (drive & path) to display
  422. during "Import a File".
  423.  
  424. 10) PKLite v 1.14 is used now, providing better encryption security.  A new
  425. message "Encryption CRC Invalid/Mismatch" displayed at startup means the
  426. security envelope has been tampered with - get yourself a legitimate copy of
  427. XRS!  Please report *ANY* occurances of this specific failure to me.  (I need
  428. to know where you got the 'mishandled' copy!)  Sorry, but the program will
  429. refuse to run if this has happened - you must obtain a legitimate copy which
  430. is original as obtained from me (and untampered with).  Your license to use
  431. XRS precludes dissassembly of the program in any way, please do not attempt
  432. to disrupt the security functions and encryption of the program!
  433.  
  434. 11) An all-new "XRInstal.Exe" program which I wrote "from scratch" (I did
  435. cheat just a bit) replaces the cumbersome old 'Automated Install' program,
  436. which was both clumsy and not designed well at all for a program which is
  437. distributed by BBS!  This new (small!) program is equally useful for both
  438. long-time XRS fans and new user setups - it will upgrade an existing copy
  439. without 'damaging' your existing CONFIG.XRS file.  This program was created
  440. with 'hyperkinetix' "Builder" v 2.03, which is a "Son-of-a-Batch" compiler.
  441. Future versions may be distributed with compressed files in *.BCF format and
  442. require XRInstal to unpack them! (of course, the BBS distribution will be in
  443. .ZIP format with "XRINSTAL.EXE", "READ-ME!.1ST" and "XRSxxx.BCF" inside)
  444.  
  445. 12) XRS properly detects and informs (on the <F2> info screen) the residence
  446. of "HIMEM.SYS" as a '386 memory manager (and its version number) as well as
  447. the new "QDPMI" DOS Protected Mode Interface host for QEMM.  
  448.  
  449. 13) XRS has been tested (no problems) under MS-DOS 6 level .015 alpha build.
  450.  
  451. 14) A problem in the file look-up for last names (activated when you hit the
  452. <INS> key after typing 2 to 6 characters of the last name at the "To Name:"
  453. propmt) was fixed up.  Sometimes it worked just fine, other times it would
  454. 'miss' certain names depending upon the filesize, etc.
  455.  
  456. 15) Sending a "User Request" to turn a message area on or off, or to do file
  457. downloads can be accomplished by hitting <F3> at the "To:" name prompt.
  458. Checking for messages to "XRS" finds anything that starts with "XRS" in the
  459. "To:" field, and truncates the name at that point.
  460.  
  461. 16) A nit that caused QWK format mailbags to have a 'funny' header when you
  462. hit <CTRL_F10> (to cause XRS to do a screen dump to $XRS$PRT.SCR) was fixed.
  463.  
  464. 17) XRS has been tested on super high-res (1260x1024) monitors at up to 132
  465. characters by 60 line and also at 100 characters by 75 line modes.  Both are
  466. perfectly readable!
  467.  
  468. =======
  469.  
  470. Changes from XRS v 5.01 -=> v 5.02 "Wide Beta"
  471.  
  472. * * *  IMPORTANT  * * *
  473. * XRS 5.02's "286" version is now a true 80286-code program - it will no
  474. * longer run on NEC V20/V30 chips!  However, it is 10% faster still than
  475. * previous versions on 80286 or higher computers.  A DOS/386 version is
  476. * under development that will be released for registered users only.  When
  477. * released, the archive will be XRS502^3.ZIP.  As of this version of XRS,
  478. * the '286 version is included in the 'standard' archive instead of the XT
  479. * - which is in a separate XRS502XT.ZIP archive (opposite of previous
  480. * verions).  My reasoning is that 90% or more people use the '286 version
  481. * anyway, and only the remaining 10% will need to get the other executable
  482. * - instead of 90% wanting the '286 as well...  XRS502.ZIP has the *286*
  483. * executable only! - XRS502XT.ZIP is the generic.  (of course - soon 50%
  484. * of them will want the '386 version - I can't win!)
  485. * * * * * * * * * * * *
  486.  
  487.  
  488. (for changes between versions 5.00 and 5.01, see below...)
  489.  
  490.  
  491. 1) If you don't open any mailbag at all (go into "Write-Only" mode), then
  492. "Buffer xxxx" space (which is used for BATxMAIL.XRS and you aren't opening
  493. it) is freed - thereby increasing available UMB or 'low' RAM by up to 32K.
  494. This occurs even if you don't change default 8K size with "Buffer xxxx".
  495.  
  496. 2) You can customize your origin line for each message by selecting them
  497. from a pick-list.  If you want to activate this feature (otherwise, XRS
  498. assigns a random one from "RANDOM.ORG" - which must exist to use this!)
  499. put the "Custom Brags" parameter into your CONFIG.XRS user profile file.
  500. Note that "Area-specific" origins override any random ones.  When you <F3>
  501. modify an existing message, if applicable - you can select a new brag.
  502. When you use this function, XRS shows you the random origin line it picked
  503. from your list (highlighted), and you are free to change it if you wish.
  504.  
  505. 3) The SysOp can send an "XORIGINS.XRS" file which overrides specific
  506. areas (only those he specifies) and locks those particular areas into a
  507. certain brag/origin line.  This way for special "alternate networks"
  508. that have required text in the origin lines can be "fixed" and the user
  509. can still either allow other areas to be randomly selected or picked
  510. using #2 above.  Note: areas specified in "XORIGINS.XRS" or "XRS.ORG"
  511. (or 'bbs_id.ORG') are never prompted for random origins, since they
  512. always use the area-specific one in those files instead.  If an area in
  513. XRS.ORG or 'bbs_id.ORG' duplicates one in XORIGINS.XRS, it is ignored
  514. (and the SysOp-defined origin is used anyway).
  515.  
  516. 4) The "XUC" program is only run for non-QWK (Fidonet) format mailbags.
  517.  
  518. 5) XRS can 'capture' brag-lines from messages (for now, only 'perfect'
  519. from Fido style, but with QWK format you have to edit a bit) and append
  520. them to your RANDOM.ORG file - adding immediately to the available list
  521. of random lines for "Custom Brags".  To capture an origin line brag,
  522. simply hit <ALT_S> ("steal") when a message is being displayed, and XRS
  523. will pop up a confirmation window with the bragline ripped-off from the
  524. current message (which can optionally be edited before saving).  If you
  525. do not want to add it, simply hit <ESC> to cancel the request.  This
  526. routine is actually available any time *except* in the internal editor
  527. (where it does *not* work!) - so you can steal an origin line even if
  528. you go do something else in-between (it always remembers the last one
  529. it 'saw'...).  If you don't already have a "RANDOM.ORG" file (and XRS
  530. looks on the PATH for it if it's not in the current directory), XRS
  531. will create one in the current directory, otherwise, the new brag is
  532. appended to the existing file.  Actually, you can use this to create
  533. any origin line "on-the-fly" and add it to your RANDOM.ORG file, too.
  534. (you might think of something 'bright' to put into a response when
  535. you are just about to save it, for example...)  Since XRS prompts for
  536. the custom brag line *after* prompting to save the message, it is the
  537. last item you get asked, and therefore you can add a new origin line -
  538. even a custom one (just use <ALT_S> and then hit <INS> to clear the
  539. captured origin line and type in whatever you want and hit <ENTER>).
  540.  
  541. 6) You can customize the "QWK brag_ID can" which identifies 'extra'
  542. origin lines and is used by the 'Nuke Garbage' filter routine by
  543. specifying your own set of 'catch phrases' in "BRAG_ID.QWK".  The
  544. old internal set of rules is used of no external file exists:
  545.     "+++ "        "-=- "        ".ORIGIN: "
  546.     " * Via "    "... "        " ■ EZ "
  547.     " * EZ "    "-- Via "    "-> MegaMail "
  548.     " ■ SLMR "    " * SLMR "    " # GateOrigin"
  549.     " * DeLuxe"    " . EZ "    "+ Megamail "
  550. This is a way to teach XRS's bragline ferret routine new QWK style
  551. readers with non-standard origin lines (or what we would call origin
  552. lines on the Fido side).  Note that if you *do* build your own, you
  553. should include all 15 strings above, too!  (your BRAG_ID.QWK totally
  554. overrides the internal table if it exists)  This table can have at
  555. most 50 entries - any additional ones are ignored.  (one entry per
  556. line - do not include the quote marks! i.e.:)
  557.  * Via 
  558. -- Via 
  559. -> MegaMail 
  560. + Megamail 
  561.  ■ SLMR 
  562.  * SLMR 
  563.  * DeLuxe
  564.  
  565. 7) I applied the second and third set of patches to my BC++ 3.0 compiler.
  566. Heck - who knows?  Could be good, could be bad!  <grin>...  Anyway - I
  567. suppose "it's fixed!" in the BC++ 3.1 compiler, right?  (yeah - right!)
  568.  
  569. 8) The data memory utilization routine is enhanced to show both the true
  570. data segment size (static data which isn't on the heap), and the actual
  571. size of the HeapXpansion instead of just multiples of 16K LIM/EMS blocks.
  572. (this is the 'hidden' "HeapWalker" function on the <F2><F2> hot-key)
  573.  
  574. 9) In any mode except "All Read Sequentially", XRS would "lose its mind"
  575. with mailbags containing > 3641 messages due to a pointer which "wrapped
  576. around" at 64K instead of always remaining normalized in some cases.  XRS
  577. always created a proper > 64K block to contain the pointers (for mailbags
  578. with more than 3641 messages) which were then loaded properly, but then
  579. 'traversing' the list failed when you hit element 3642 and everything
  580. went downhill.  XRS for DOS is now capable of reading a 100,000 message
  581. mailbag (and still "Preload Summary" if you have 2MB of LIM/EMS memory).
  582. Since I didn't want to say I had 'fixed it' unless I was sure, I created
  583. a big-bad-mean-mother mailbag of 11582 messages and XRS choked it down,
  584. had 1.2MB of total heap space (including 270K+ on the far heap, 120K in
  585. UMB heap space and 800K in HeapXpander (LIM/EMS) memory).  I did all the
  586. nasty things one would try, like popping up jump lists, backtracking to
  587. previous messages, writing replies, marking messages read from the <J>ump
  588. list, exporting mail, hopping from message 11403 to 32 latterally, etc.
  589. Couldn't seem to break it - the heap was still uncorrupted, the MAILxIDX
  590. file was properly updated, and everything went just fine.  XRSRT386.EXE
  591. beat the mailbag into threaded/sorted order in just under one minute, and
  592. required slightly under 900K of free memory to sort the list.  Obviously,
  593. a list of this size cannot be sorted using the standard or '286 XRS-Sort!
  594. (Out of this 60 seconds, approximately 45 was doing file I/O, wherease the
  595. 11582-message sort only took about 15 seconds using the flat '386 model.
  596. It takes slightly over 134 million compares to sort a list of that size!)
  597.  
  598. 10) In working out the kinks above, I found I was doing a linear geometric
  599. search to fix the end-of-message pointers when XRS*Sort is used, causing
  600. XRS to search (total_messages ^ 2) items (i.e. 36 million checks for 6000
  601. messages!).  I rewrote the routine sorting the offsets first, then using a
  602. binary search lookup, which is from 2500% to 55000% faster (or even more!)
  603. depending on the number of messages (the more messages, the more noticable
  604. the speed difference will be).  (25x speed example is for a 250-message
  605. mailbag, 350x speedup example is a 6000-message mailbag.  A 10,000-message
  606. mailbag would be 550x faster!)  Loading sorted mailbag indexes (due to the
  607. auto-linking of threads) and finding the true end-of-message pointers for
  608. sorted mailbags takes much longer than for unsorted mailbags (the latter
  609. step doesn't even have to be run), so I added a couple of tally counters
  610. where the system appeared to "go dead", although it was working furiously.
  611. Note that there is a point where you "hit the wall" when XRS can no longer
  612. both load the MAILxIDX.XRS file into memory and "QuickSort()" the sorted
  613. end-of-message pointers - at which point XRS has to drop back and punt and
  614. use the old tried and true (but painfully slow!) routine instead.  I was
  615. easily able to QuickSort() a 6000-message mailbag, but the 11582-message
  616. mailbag sent me out on a coffee break.  I suspect the actual line is about
  617. 8000 messages or maybe slightly less (this assumes you have 50K of UMB's
  618. free on a '386 machine, use DOS 5 with "DOS=HIGH" and have minimal impact
  619. on your "low" [640K] memory usage).  I recoded the original routine again
  620. after I found out how huge the difference was, and improved the speed of
  621. the routine by 25% by using "register" variables, too. (it is used seldom
  622. now anyway - only if you gag XRS with a huge mailbag!)
  623.  
  624. 11) If you had a mailbag with duplicate message numbers in different areas
  625. and one of those areas was large enough to activate the "Virtual List"
  626. feature of the message viewing <J>ump list, then XRS would refuse to 'back
  627. up' any further than the first message # matching the lowest message # in
  628. the area being viewed, and it would also refuse to advance any further
  629. than the highest message # in the area (whether or not the message's group
  630. matched the group #).
  631.  
  632. 12) Sometimes "AutoTag/Match" and <F8> search/mark/tag didn't always find
  633. every match.  This was a bug apparently introduced in a recent version -
  634. I didn't check to see exactly which revision it was when I screwed it up.
  635. (it was *only* finding them if the first letter was capitalized!)
  636.  
  637. 13) Since there was so much new code (all of which was overlay-able), I
  638. increased the overlay cache buffer size to 160K (of LIM/EMS or XMS - if
  639. you have it).  I also split one overlay into two pieces, one of which is
  640. seldom (if ever) called during a normal XRS session.  This lets XRS still
  641. run in the same memory required for previous versions even with all the
  642. new functionality.
  643.  
  644. 14) The <F3> (tag for export) and <DEL> (mark for deletion) in the <J>ump
  645. list doesn't skip every other message if you hold it down (and associated
  646. similar behavior related to the above is also corrected).  Actually - if
  647. you were reading normally (inside an area instead of "All Read...") these
  648. toggles weren't working from the <J>ump list at all - although they *did*
  649. display signals which made it *look* as if they were working (sometimes).
  650.  
  651. 15) You must confirm your choice when you select "Delete All" (mailbag).
  652. Selecting either "No" or hitting <ESC> from the confirmation window will
  653. return you to the "Empty mailbag" option menu to make another selection.
  654.  
  655. 16) Overlay structure was hand-balanced again, for smoother operation.
  656.  
  657. 17) This version is linked with the latest RTLink+ v 5.02 update.  For
  658. those of you that have been running any 5.0x version (at all - even the
  659. 5.02/alpha1), please do not inform your old XRS that it doesn't work!
  660. (RTLink+ 5.02 was put out to add BC++ 3.0 compatibility?!?)  If you have
  661. problems with XRS -vs- either EMS or XMS memory, you may need to disable
  662. the RTLink+ caching overlays *before* you start the program (if so, the
  663. program should tell you how to do so, and exit 'gracefully').  This will
  664. only happen if there is a problem with your implementation of EMS or XMS
  665. memory.  Specifically, if you think you are having XMS memory problems
  666. preventing XRS from starting - "SET RTOVEXT=0" before you run the program.
  667. Similarly, if you are having problems possibly related to EMS memory,
  668. "SET RTOVEXP=0" before you run XRS.  Under normal circumstances, neither
  669. of these settings is needed, but if you use them, they force the RTLink+
  670. overlay caching code to skip EMS and/or XMS memory testing altogether.
  671.  
  672. 18) A "strcat()" function where there "strcpy()" should have been used
  673. was responsible for XRS occasionally hanging on startup.  For some reason
  674. this was only triggered (apparently) when the RESP_*.EXE file was not in
  675. the current directory when you started (and even then - it depended on
  676. what was in memory before-hand...).  It looks like it was clobbering the
  677. open files immediately after the storage for the string.  Stranger still,
  678. in the "TELOS" (non-shareware for United Church of Canada) version the
  679. exact opposite symptom occurred: XRS wouldn't start *if* the RESP*.EXE
  680. was in the current directory!
  681.  
  682. 19) TCXL 5.52 update 6 was installed, cleaning up some of the oddities in
  683. the EMS & XMS memory query.  This new version should also detect and use
  684. Windows 3.x 386/enhanced mode's "Alternate Video Buffer" (similar to the
  685. Desqview method of assigning an alternate area for direct screen I/O).  A
  686. corrupted _BX register in the Hercules support initialization was fixed.
  687.  
  688. 20) The problem (which only occurred in 5.02/alpha1!) where XRS would go
  689. nuts after trying to edit your main brag/origin line (selecting 'O' from
  690. the <F4> hot-key pop-up configuration menu).  Also, formerly - XRS would
  691. save the brag/origin line even if you hit <ESC> here - it no longer does.
  692. The same thing happened if you have an alpha copy of XRConfig.Exe and
  693. popped it up over the <F4> hot-keyed configuration window - this new
  694. completely graphical (both DOS and Windows) XRS configuration program is
  695. almost ready to release, now that the "Zinc" Interface Library 3.0 has
  696. been received.  It's been completely redesigned from the ground up, and
  697. has nothing but radio buttons for "multiple choice" items, check boxes
  698. for "Yes/No" options and a set of string and/or size prompts only for
  699. those fields which require a buffer size or file/path for example.
  700.  
  701. 21) Fixed a couple of cosmetic (display and log) mess-ups when the "To:"
  702. name was exactly 25 characters long.  Packets were correctly formatted...
  703.  
  704. 22) The space bar during Optimized Viewing of multiple screen messages
  705. scrolls the same number of lines as <PAGE_DOWN> (instead of 1 less).
  706.  
  707. 23) An OS/2 v 2.0-specific Icon is included (XRS51OS2.ICO).
  708.  
  709. 24) Since I found (and fixed) the problem which caused XRS to reload with
  710. really wierd DOS version numbers (which if > 9 make it *look* like you
  711. are using a "DOS Box" under OS/2), I added back the "OS/2" moniker to the
  712. tear and ^aPID: lines.
  713.  
  714. 25) After XRConfig is run from the <F4> hot-keyed configuration window
  715. (by hitting <F4> again - XRS only offers - and allows - this if it sees
  716. XRCONFIG.DAT and XRCONFIG.EXE in the directory or somewhere on your PATH)
  717. XRS now properly resets the video screensize if you were in an 8x8 mode.
  718. XRConfig 0.08/alpha was current as of this writing, and 0.50/beta should
  719. be available coincidental with release of XRS 5.02!  XRCFG050.ZIP will be
  720. the filename - until superseeded by a later release.  For now, XRConfig
  721. will be separate from the regular release archive file, so it can be
  722. easily replaced, but future versions of XRS will come with the current
  723. XRConfig.  (WinXRCfg, which is ready but I have no reason to release now
  724. unless someone just wants it to play with it - is identical, as will be
  725. future OS/2 PM and possibly *nix-flavored ("Open Windows" or more likely
  726. "Motif") versions.  XRConfig adds a whole new dimension to the world of
  727. XRS - especially for new users!  You can now easily install and configure
  728. XRS without ever having to consult a manual, since XRConfig has built-in
  729. detailed context-sensitive help for every option/parameter.  With both
  730. XRConfig and XRS's "AI" (Automated Installation) programs, new user setup
  731. is easier and quicker than ever - and new users can be "up and running"
  732. with an optimal configuration in no time!
  733.  
  734. 26) Now linked with RTLink+ 5.10 (these guys are trying to keep up with
  735. me <grin>...).
  736.  
  737. 27) Compiled with Borland C++ 3.1 - here's to good luck!  See note about
  738. major change in the way distribution archive are put together up top...
  739.  
  740. 28) More of the part of the program that is required to be memory-resident
  741. during execution is bound into the "root" segment - the RESP*.EXE portion
  742. as opposed to the RESP*.DLL part.  This makes the XRSCORE.DLL significantly
  743. smaller, and the root portion only slightly smaller.  In the '386 version,
  744. the RESP_386.DLL is small enough to only require 144K to cache overlays as
  745. opposed to 160K required by both the '286 or "XT" versions.  None of this
  746. affects the run-time load size, just moves part of it and compressed more.
  747. One of the most noticable side-effects of this change is that all versions
  748. load (and reload) a little faster than before.
  749.  
  750. 29) Since XRS knows that XRConfig is a road-hog (graphics-based programs
  751. just are...) it always swaps out even if the "Swap" parameter is not on.
  752.  
  753. 30) Having an XORIGIN.XRS file is not fatal (only happened in /alpha2).
  754.  
  755. =====
  756.  
  757. Changes from XRS v 5.00 (With no "Mods") -=> v 5.01 "Wide Beta"
  758.  
  759.   ┌───────────────────────────────────────────────────────────────────┐
  760.   │  These are listed in 'as-added' order - if you already have some  │
  761.   │  or all of the 5 patch kits ("mods") applied to your copy, some   │
  762.   │  of these may not really be "new" for you.  The items toward the  │
  763.   │  bottom of the list were added most recently, and each revision   │
  764.   │  has a "waterline" marker between changes so you can easily tell  │
  765.   │  which changes were applied at each mod level and also between    │
  766.   │  XRS 5 "Mod 5" and this new "Wide Beta" 5.01 version.             │
  767.   └───────────────────────────────────────────────────────────────────┘
  768.  
  769.  
  770.  
  771.  
  772. ==== (Start of 5.0 Mod 1 & 2 Level Changes) ====
  773.  
  774. 1) XRS "bottom-line" time clock uses the native language format and date
  775. separator properly (again).
  776.  
  777. 2) XRS doesn't give a "Security Error '0xbad'" exit on non-80-column width
  778. screens for unregistered users.
  779.  
  780. 3) If XRS is allowed to "auto-size" in a non-standard mode, it doesn't
  781. mistakenly assume that it's back in 25-line mode when it returns to the
  782. "normal" font.  For example, this would cause XRS to autosize from 37- or
  783. 40-line mode to 75-line mode and back to 37-line mode on my machine, but
  784. place text and messages on exit as if the screen-size were 25 lines.
  785.  
  786. 4) After entering the editor one time, hitting <ALT_F3> or <ALT_F5> when
  787. no longer in the editor no longer causes bizarre results and/or hangs.
  788.  
  789. 5) While in the "Color Palette" routine (via the <ALT_F7> hot-key) XRS
  790. disables all interrupt function keys used by the internal text editor.
  791. I also corrected the alignment of the color selection list for screens
  792. wider than 80-columns.
  793.  
  794. 6) The annoying 'flash-blink-flash' during "List View" display on slower
  795. machines (when you <ESC> or <Enter> to the menubar) is mostly eliminated.
  796. Also, the display of the "Saving Message Index" informational message is
  797. before each message is displayed instead of afterwards, which contributed
  798. added delay in the above sequence if you were using "Safe Mode".
  799.  
  800. 7) The mouse cursor doesn't disappear (until you move the mouse or reset
  801. it) immediately after a "Preprocess" routine is called.  Also, after doing
  802. an <F8> (or "Auto...) Match/Tag the mouse cursor returns immediately.
  803.  
  804. 8) In the TELOS-specific version (non-shareware), <ESC>aping out of a pick
  805. list of one element during area selection for message reading doesn't cause
  806. a screwy "Auto Cycle" instead of just dropping back to the main menu.
  807.  
  808. 9) <ESC>aping out of message creation after selecting an area which is
  809. either private-only or lets you choose (and you chose private) does not
  810. make the next message private regardless of area.
  811.  
  812. 10) Someone noted that multiple substitutions of the same element into a
  813. macro or attribution line didn't work.  Well, I didn't intend for it to!
  814. (since I couldn't think of any example where you would want to repeat the
  815. same variable twice, but - I tossed in the code to handle it...)
  816.  
  817. 11) Replies to messages for areas a user is not authorized to use (because
  818. of security changes) are always marked private and put into the LOCAL area.
  819.  
  820. 12) XRS doesn't display a phantom extra message at the end during "All Read
  821. Chronological".
  822.  
  823. 13) Fixed quoting (or export in quoted format) the last message.  A related
  824. bug - taking forever to find the end of the next-to-last message was fixed.
  825. These both only occurred if you used XRS-SORT.EXE or any of its variants,
  826. because the "end-of-message pointer" fix routine for 'abnormal' mail
  827. indices was not taking the final element in the unsorted list into account.
  828.  
  829. 14) Fixed a bug which caused XRS to stop reading messages during "All Read
  830. Chronological" when it hits the last physical message in a mailbag.  Again,
  831. this only occured in sorted mailbags.
  832.  
  833. 15) XRS doesn't "adjust" the SysOp-defined description for the first local
  834. area used to be truncated to read only "LOCAL", and the forced remapping of
  835. the first "local" group to group # 0 is gone.  SysOps should be sure they
  836. offer all users access to at least one local area where they can leave
  837. private messages, so users without access to netmail can send messages to
  838. the SysOp (and other users).
  839.  
  840. 16) Fixed a bug which caused messages after being XRS-Sort'ed in "All Read
  841. Chronological" to be displayed at random if no "ToYou" or "NewOnly" filter
  842. was on.
  843.  
  844. 17) "All Message Read (Chronological)" is now called "All Message Read
  845. (Sequentially)" instead.  This distinction is because the messages are no
  846. longer chronological if they have been XRS-Sort'ed.
  847.  
  848. 18) CONFIG.XRS allows you to "Hide Mouse" out of the default center of the
  849. viewport, 'hiding' it in the lower right-hand corner instead.  Note that
  850. this will cause the mouse cursor to seemingly disappear until you move it.
  851. (and will do so each time the mouse is re-initialized, like when you exit
  852. from the <F10> DOS shell - until you move it again)
  853.  
  854. 19) The "DOS Critical Error Handler" has been enhanced to make it a little
  855. more obvious and center the actual error message as interpreted from DOS -
  856. flashing in a single-border window with the active "Abort, "Retry", "Fail",
  857. "Ignore" selection in a double-bordered window.  Note that during a DOS
  858. critical error, no interrupt routines can be called, so the mouse is not
  859. active at that point (if you have a mouse you must still select an option
  860. with keyboard).  To allow for screen resizing, the portals for both the
  861. error message and "Abort, Retry, Ignore, Fail" windows must be built in
  862. advance, and now will always appear on lines 6 and 12 of the display
  863. regardless of screen-size.  Also, the default is pre-selected as "Retry"
  864. instead of "Abort".  In this case (and in any DOS Critical Error Handler!)
  865. "Abort" means just that - blow XRS out of the water without cleaning up!
  866.  
  867. 20) XRS now accepts up to ten "Twit" phrases, which match the To:, From:
  868. and Subject: lines using a "proximity" search, so if a twit keyword you
  869. give is found anywhere in the three fields, the message will be twitted.
  870. If you twit "Bill", for example, you twit all messages to or from anyone
  871. named Bill, with a lastname containing "bill" plus any that happen to have
  872. a subject that contains the letters 'bill' in order.  If you use a complete
  873. name, messages to or from that person (or with their name anywhere in the
  874. subject) are skipped - if you use a topic, be sure it isn't too short and
  875. likely to match a lot of names or other similar subjects.
  876.  
  877.  
  878. ==== (Start of 5.0 Mod 4 Level Changes) ====  ("Mod 3" was 'internal' only)
  879.  
  880. 21) A new meta-symbol "%b" is available for macros and attribution lines
  881. that uses the AREA: name - as opposed to '%a' which uses its description.
  882.  
  883. 22) The first group marked local or starting with the word "Local" is the
  884. one selected to remap mail for areas no longer available, or on boards
  885. where the user does not have access to the mail normally, but it is found
  886. outside the selected areas because the name matches exactly.  Previously,
  887. this was only the first group which started with the word "Local"...
  888.  
  889. 23) "Read-Only" groups show on the message read area selection list.  (but
  890. you cannot enter a message)
  891.  
  892. 24) "No Reply" areas are supported.  These areas allow read access but no
  893. quote or reply, and allow you to originate new messages as well.  This is
  894. not currently possible with output of any XRS door, but XRSDoor 2.06 will
  895. support it if the SysOp choses to make the "Read-Only" bit mean "No Reply".
  896.  
  897. 25) If you reply to a private message, the default is private again.
  898.  
  899. 26) You can mark messages for deletion (actually done with "XRSlice.Exe").
  900. The C_Worthy "MenuBar()" source-code was modified to allow the entries in
  901. the menubar to appear one character closer together to make more room.
  902.  
  903. 27) XRS recognizes two new BBS types: "TAG", and "MK".
  904.  
  905. 28) Output to LPT2: or LPT3: also gets a "Form Feed" at end if enabled,
  906. and exporting messages from the mail reading MenuBar to a printer other
  907. than LPT1: is performed to the proper device instead of STDPRN (LPT1:).
  908. Also, XRS checks the status of printer devices before attempting any I/O.
  909. If the printer is unavailable, you will be told and your request ignored.
  910. If it is offline or out of paper, you will be informed and then you can
  911. cancel or retry the output.
  912.  
  913. 29) The long-standing bug in the C_Worthy library (which still isn't fixed
  914. in the 2.03 version!) which causes areas to appear marked that should not
  915. (especially after you hit the bottom of the message and <PAGE_UP>, etc) is
  916. finally found and fixed.  This bug only affected the internal editor.
  917.  
  918. 30) XRS highlights all displayed "kludge" lines in blue.  Also, previously
  919. if "^aEID:" or "^aMSGID:" lines were in the text, they were not displayed
  920. (and now they are).  The XRS-specific "FROM-ADDRESS:" kludge in netmail is
  921. also highlighted in whatever you have set in the "In a message..." color.
  922.  
  923. 31) XRS supports AREA: tags up to 60 bytes (per the coming FTS-0004.002)
  924. and 40 bytes description for the "SysOp-defined description" for each
  925. area.  (the old limits were 37 and 32 bytes)
  926.  
  927. 32) The "Search/Tag/Mark" routine doesn't leave an extra "x lines scanned"
  928. off to the right side if/when you "Hide" the search.
  929.  
  930. 33) If you want XRS not to turn on the "ToYou" filter automatically (and
  931. therefore not show you messages to you first instead of in sequence), you
  932. can put "ToYou Off" into CONFIG.XRS which causes XRS not to turn it on.
  933.  
  934. 34) If you hit <F7> to Unmark (UnRead) All messages while the "To You" 
  935. filter is on, only messages that are to you are unmarked.
  936.  
  937. 35) XRS offers the "Repack/Delete/Both/Neither" and other exit options if
  938. you are using an external bundler.
  939.  
  940. 36) Part of this was in v 5.0 "Mod 4", but has been enhanced for 5.01:
  941. "List View" mode has undergone a major "overhaul".  During message view
  942. mode, the spacebar acts the same as "Page_Down", any non-scrolling key you
  943. hit is considered to be a command key (such as "Next", "Quote", "Reply",
  944. "Back", etc) and passed to the underlying menubar routine after terminating
  945. message view mode.  If the key you hit isn't a valid option for the
  946. menubar, then you will get a beep - and need to select another (valid)
  947. option (in other words, XRS makes no attempt to 'validate' the keystroke,
  948. merely passing it to the "menubar" routine - this allows me to have foreign
  949. native language support without needing to 'know' which keys are valid).
  950. Also, in "List View" mode, a 'place-holder' appears onscreen to show if an
  951. incomplete screen is displayed when you hit "PageDown".  It shows you where
  952. to start reading new material, just like in "Page View" mode.  XRS builds a
  953. 'fake' menubar just like it would show for each particular message.  This
  954. currently only recognizes English "Capital" letters, i.e. 'A'..'Z' - if
  955. someone will provide me with a proper subset of the high-ascii foreign NLS
  956. characters in the IBM character set that are "Capital" letters, I'll put
  957. them in the hit list for the foreign NLS users, just in case you're using
  958. an "odd" (for English) hot-key (otherwise, the foreign Capital letter
  959. won't be highlighted!).  Note that the pseudo-menubar *is* "hot" but not
  960. really "live" in the sense that you cannot move the highlighted selection
  961. as you could with the left and right arrow keys if the message were less
  962. than a single screen-full.  This also means if you want to select an item
  963. from it with the mouse, you must hit the right button first!  (and then
  964. click on the option with the left button...)
  965.  
  966.  
  967.  
  968. ==== (Start of 5.0 Mod 5 Level Changes) ====
  969.  
  970. 37) During Color Cascading of matched text on monochrome screens, the
  971. color doesn't fade to black (and stay there).
  972.  
  973.  
  974.  
  975. ==== (Start of 5.01 "Wide Beta" Changes) ====
  976.  
  977. Finally...
  978.   Michael Barnes' XUC ('eXpress Userlist Compiler') is fully supported!
  979.  
  980. 38) Full support for the XUC format (normally "USERFILE.XUC") user name
  981. list file is included.  XRS searches USERLIST.XRS first, then the XUC
  982. USERFILE.XUC (if it exists, or you may specify an alternative name with
  983. path if needed - otherwise USERFILE.XUC should be in current directory)
  984. followed by up to two user-specified "USERLIST xxxx" in 'FidoUser.Lst'
  985. format files.  To specify a different filename for the XUCList (if any)
  986. use "XUCList Z:\PathName\FileName.Ext" in CONFIG.XRS - this file will
  987. override USERFILE.XUC even if that file exists in the current directory!
  988. If XRS finds multiple exact name matches in the XUC format user namelist
  989. they will be displayed and you will have to select a destination address.
  990. Also, if you place the new parameter "XUC" into your 'CONFIG.XRS' file,
  991. XUC will be called immediately after a preprocess function is called.
  992. This allows you to specify XRS*Sort as a preprocess for new mailbags,
  993. and have XUC automatically accumulate all new names and addresses in
  994. each new mailbag.  Note that the "new" condition is just as before:
  995. either a newly unpacked mailbag is opened, or "Force New" appears in
  996. your 'CONFIG.XRS' file already.
  997.  
  998. 39) XRS has a built-in auto-lookup for names (and address) which uses
  999. both the existing (up to three) UserList.XRS format files plus the XUC
  1000. format file Michael Barnes designed.  If XRS 'sees' "USERFILE.XUC" in
  1001. the current directory, it will automatically use it whether or not you
  1002. specify it, or you can name your XUCList in the CONFIG.XRS parm file:
  1003. "XUCList X:\SOMEPATH\XUC_FILE.NAM" (but XRS only reads one XUC format
  1004. userlist!).  The order of search: USERLIST.XRS (if it exists), followed
  1005. by USERFILE.XUC (or whatever you specify for "XUCList") next, then up
  1006. to two optional files named in "UserList xxx" parameters (if any).  The
  1007. auto-lookup search is triggered by typing from two to six characters of
  1008. the *LAST* name and hitting <INSERT>.  Instead of clearing the name
  1009. field (which it still does if there is one or more than six letters!),
  1010. it creates a pick-list of names which match the two-to-six characters
  1011. you typed, and you may either select one (if so, be certain to pick the
  1012. one with the correct address if this is netmail, the address you pick
  1013. will be used automatically without prompting!) - or hit <ESC> to return
  1014. to the name entry prompt and try again.  You should remember that using
  1015. this method causes XRS to search all files regardless of whether an
  1016. exact match is found or not (unlike the auto-address lookup), so if you
  1017. have two or more very large lists, XRS may take a moment to do a binary
  1018. search of all applicable files and present a list.  Picking a name from
  1019. the list which results from the search both sends the message to that
  1020. receipient and also uses the netmail address picked (if you are sending
  1021. netmail) automatically without later prompting for an address.  If no
  1022. pop up list appears after searching, (XRS goes back to the name prompt)
  1023. there were no matches found at all in any of the user namelist files.
  1024. The actual lookup is "hot" - meaning that if you type "RAT" and hit the
  1025. <INS> key, after the list pops up with your choices, hitting more keys
  1026. will narrow the search (i.e. typeing "LED" at this point would hilight
  1027. one of my addresses, because I'm the only one in the nodelist starting
  1028. with "RATLED").  This doesn't change the list content, but rather moves
  1029. the pointer in the list to best match what you type.  The entries in a
  1030. name pick-list are marked as follows: "1" = Primary USERLIST.XRS file,
  1031. "2" = Secondary USERFILE.XUC, "3" = First user-specified UserList file
  1032. (from CONFIG.XRS) and "4" = Secondary user-specified UserList file.  If
  1033. any user namelist file is > 30K the search is quickly narrowed using a
  1034. trisecting binary search and no more than 8% of the file is read total.
  1035. (which should result in excellent lookup response times even when all
  1036. four lists are searched!)  You can then easily narrow the search by
  1037. typing one or several more characters until you find the correct name,
  1038. and then hit <ENTER> to complete the process.  XRS uses a "caseless"
  1039. sort here, so 'homrighausen' doesn't show up somewhere before all the
  1040. 'A' names, etc <grin>...  (in other words, names are sorted caseless)
  1041.  
  1042. 40) The "ColorList()" routine I customized from C_Worthy to handle the
  1043. visually scrolling list which now allows "hot" access to command keys
  1044. if you us "Optimized View" mode (try leaving out "Page View" even if
  1045. you have been using it since day 1!) now actually scrolls a full page
  1046. up or down instead of (x - 1) as before.  (in other words, you don't
  1047. have to skip over the first line each time you page down - and if less
  1048. than a full new page is displayed, a visual marker as described above
  1049. in feature update #43 is on-screen to show which line you last read)
  1050.  
  1051. 41) Color cascade shouldn't "stall" as often when there are many items
  1052. highlighted onscreen at one time. (like more than a dozen...).
  1053.  
  1054. 42) Repacking a mailbag retains the original file's date & time stamp.
  1055. It will actually "Deja vu" the files, repacking them with the original
  1056. timestamp even if they have already been repacked with an intermediate
  1057. time somewhere along the way (if you reopen and repack an old mailbag
  1058. it will regain its original timestamp, for example).
  1059.  
  1060. 43) Other C_Worthy-based programs seem to have settled on using the
  1061. (normally green) 'Help' palette for the bottom-line help.  If you want
  1062. this instead of the 'Normal' palette put "Help Palette" in CONFIG.XRS.
  1063.  
  1064. 44) Under OS/2 2.0, XRS recognizes and uses virtual EMS and/or XMS.
  1065.  
  1066. 45) XRS doesn't leave little chunks of UMB's allocated sometimes.
  1067.  
  1068. 46) You can <ESC>ape out of the <J>ump list to the previously viewed
  1069. message.  This only works correctly if you immediately <ESC>ape after
  1070. popping up the <J>ump list before entering other positioning commands.
  1071.  
  1072. 47) Messages marked for deletion are tagged with '≡' in <J>ump list.
  1073.  
  1074. 48) You can mark/unmark messages for deletion using the <DEL> key in
  1075. the <J>ump list.  When they are marked for deletion, they are marked
  1076. read - if they are unmarked for deletion, they are also unmarked read.
  1077.  
  1078. 49) XRS now prompts you asking permission to call XRSlice to delete
  1079. all messages you marked for deletion (if any).  This (along with the
  1080. three other new features above) allows you to use XRS as a database
  1081. type message system when used in conjunction with programs from Rudi
  1082. Kusters' "XCS" system of programs.  The prompting for this occurs
  1083. immediately after prompting for permission to write messages tagged
  1084. for archive only if you have "Always" in your "CONFIG.XRS" file.
  1085.  
  1086. 50) Another hand-optimization of the overlay structure leads to lower
  1087. run-time memory requirements than any previous 5.0x version, and also
  1088. makes some operations a little quicker.
  1089.  
  1090. 51) Under OS/2, TCXL 5's "UMB" support seems to either be freakin' out,
  1091. or OS/2 is feeding it bad dope!  (I get wierd things like "12K largest
  1092. block" but "4K total free" and can't allocate any UMBs)  For the time
  1093. being, UMB support is disabled under OS/2.
  1094.  
  1095. 52) Marking messages Read/Unread (or Tagged/Untagged for export, or
  1096. Marked/Unmarked for deletion) matches the message area as well as the
  1097. message number.  This is not significant to most users - but QWK users
  1098. have multiple message areas (XRS supports 1024) with duplicate numbers
  1099. in each area allowed, unlike the "Hudson-style" message base XRSDoor
  1100. exports messages from (which like the underlying database doesn't have
  1101. duplicate message numbers at all).  Under this condition (reading a
  1102. QWK format mailbag with multiple messages having the same message
  1103. number), XRS was picking the first "hit" on the message number to
  1104. toggle Read/Tagged/Delete on and off instead of continuing the search
  1105. until both message number and area matched.
  1106.  
  1107. 53) I have documented cases of XRS losing it's mind as far as to what
  1108. version of DOS (or OS/2) it's running under when it has been restarted.
  1109. This is undoubtedly the result of Borland's C++ 3.0 "exec...()" bug I
  1110. have already reported (and they supposedly fixed...) before.  I sent in
  1111. another 'bug bitch report' to Borland on CompuServe, but haven't heard
  1112. back yet.  For the time being, I have to drop back to DOS if it (the
  1113. _osmajor._osminor setting) is really whacked - you can restart XRS
  1114. yourself with <F3> or <UP>.  Sometimes even this is "fatal" and locks
  1115. up your machine - I'm afraid I really can't do a thing about it!  This
  1116. is also the culprit in the few cases where XRS reported "DOS 3.0 or
  1117. higher required" on restart...  I can sometimes tell when it's going to
  1118. happen before it happens, and if I'm certain re-executing XRS will
  1119. cause the problem, I don't offer to "Restart XRS?" at all for now.
  1120.  
  1121. 54) XRS calls the DOS shell slightly differently when swap/spawning,
  1122. and also calls external programs slightly differently if there are no
  1123. parameters being passed when swapping is enabled.  Hopefully this will
  1124. cure problems with wierd parameters and/or environments being "lost".
  1125.  
  1126. 55) XRS allows for funky (and incorrect!) replacement DOS command
  1127. interpreters that do not delete all files with one or two characters
  1128. during a "DEL ??.MSG" call.  (It does so by deleting "?.MSG", checking
  1129. for more messages and nuking them.)  This should work in every case!
  1130.  
  1131. 56) Ralf Brown issued a new version (4.1) of his "SpawnO()" swapping
  1132. routines.  This fixes several things I have reported and had to work
  1133. around before: No "blown" environments any more, the "SET TEMP=" and
  1134. "SET TMP=" environment variables are not "burned in" (or rather out)
  1135. and in fact if you swap-to-disk (have either no or not enough EMS or
  1136. XMS memory), they are used instead of the drive in a "Swap X" parm.
  1137. You can even override "all the above" (for disk swapping) by using a
  1138. new "SET SWAPDIR=xxx" parameter - which may contain multiple drives
  1139. (listing multiple directories on the same drive doesn't make much
  1140. sense: if there's not enough space in one dir, there's not going to
  1141. be space in another on same drive!).  Example: "SET SWAPDIR=F:\;C:."
  1142. will try the root of the F:\ drive first, and if not enough space is
  1143. available, will use the current directory on the C: drive instead.
  1144.  
  1145.  
  1146. Changes from original XRS v 5.01 -=> May 3rd, 1992 edition v 5.01
  1147.  
  1148. 57) Under certain conditions, if you used the <ALT_F10> hot-key exit out
  1149. of XRS, it was possible XRS would forget to deallocate a set of several
  1150. UMB memory blocks on a '386 or higher processor (if you allow the UMB
  1151. support).  This was rare, but could happen in several different places.
  1152. I now keep a doubly linked-list chain of UMB's allocated in memory and
  1153. purge any leftovers in the "exitproc()" routine properly - no matter if
  1154. you are in the editor (or wherever) and hot-key out with <ALT_F10>.  I
  1155. walk the linked list and free anything that would previously have been
  1156. left "hanging" (until you rebooted).  I added UMA block information to
  1157. the "HeapWalk" hidden routine which pops up if you hit <F2><F2> (since
  1158. it really is part of the heap!).  Information on any HeapXpander memory
  1159. is also shown in the HeapWalk routine.
  1160.  
  1161. 58) Ralf Brown fixed the "SpawnO()" swapping functions so that the _PSP
  1162. isn't destroyed during swapping.  XRS can now safely restart any time
  1163. and no longer skews the _osversion.
  1164.